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PROCEDE DE COMMUNICATION ENTRE UNE CARTE A PUCE ET UNE STATION 

— L/jnvention concerne un procede de communication 
entre, d une part, une station hote telle qu'un ordinateur per- 
sonnel et, d'autre part, un objet portatif a microcontroleur tel 
qu une carte a puce, ledit objet portatif etant connecte, par 
un systeme de bus, a ladite station hote. ^invention se ca- 
ractense en ce que le procede comporte une etape selon la- 
quelle une requete speciflque est communiquee a robjet 
portatif a microcontroleur par la station hote. (.'invention 
s applique en particulier a des cartes a puce susceptibles de 
communiquer directement avec un ordinateur hote selon le 
mode transfert de controle de la norme USB 



HOTE. 
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PROCEDE DE COMMUNICATION ENTRE 
UNE CARTE A PUCE ET UNE STATION HOTE 

Les cartes a puce sont des objets portatifs normalises definis dans la norme 
ISO 7816, qui permettent notamment d'assurer une gestion securisee de 
5 donnees confidentielles et d'identification. De maniere a communiquer avec le 
monde exterieur, ces cartes utilisent generalement des protocoles de 
communication d6flnis dans les parties troisieme et quatrieme de la norme 
precitee. II s'agit en particulier du protocole bien connu de Phomme du metier 
sous la denomination T=0 (t egal a zero), qui met en oeuvre des commandes 

10 d*un format defini : les commandes APDU (Application Protocol Data Unit). 

La norme USB (Universal Serial Bus), qui decrit un systeme de bus serie 
universel, a ete developp6e pour assurer une gestion simple et rapide des 
echanges de donnees entre une station hote, par exemple un station de travail 
formee par un ordinateur personnel, et un dispositif peripherique quelconque, 

15 par exemple une imprimante ou un clavier, ^utilisation de ce systeme presente 
de nombreux avantages. Tout d'abord, il necessite deux lignes conductrices, 
V BUS et GND, pour Palimentation du dispositif peripherique et deux lignes 
conductrices, D+ et D-, pour une transmission differentielle des signaux de 
donnees. D'autre part, il autorise des vitesses de transmission des donnees 

20 generalement superieures a celles proposes par les liaisons series 
classiquement installees sur les ordinateurs personnels. Ces vitesses sont de 
12 Mb/s (Mega bits par seconde) en ce qui concerne la vitesse pleine et de 1,5 
Mb/s en ce qui concerne la vitesse basse. Ensuite, il permet un «Plug & Play» 
a chaud des dispositifs peripheriques, c'est-&-dire une reconnaissance 

25 dynamique desdits dispositifs par I'ordinateur hote. Grace a cette 
reconnaissance, les pilotes des dispositifs peripheriques, qui resident dans une 
memoire de masse de I'ordinateur hote, sont charges dans une memoire vive 
dudit ordinateur uniquement a la connexion desdits peripheriques. Ces memes 
pilotes sont decharg6s de ladite memoire vive a la deconnexion des 
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peripheriques. En outre, le systeme de bus serie universel rend possible une 
connexion jusqu'a 126 dispositifs peripheriques en cascade sur un unique port 
physique USB. Enfin, les peripheriques USB ne monopolisent pas d'interruption 
materielle IRQ (Interrupt ReQuest) geree les composants de I'ordinateur. 
5 Aujourd'hui, le besoin de securisation de I'acces aux stations hote ainsi 

que de I'acces aux serveurs associes auxdites stations est grandissant. II en va 
de meme pour le besoin de securisation des transferts de donnees gerees a 
partir de telles stations, en particulier a partir de logiciels applicatifs desdites 
stations dedies notamment aux mels ou a la navigation sur I'lnternet, et pour 
10 lesquels on souhaiterait une authentication des donnees au moyen 
d'algorithmes de cryptage permettant de certifier lesdites donnees et de les 
signer. 

Compte tenu de I'etat de la technique prealablement expose, on a 
naturellement repondu aux besoins de securisation precites en utilisant des 

15 cartes a puce, fonctionnant selon les protocoles organises par les parties 
troisieme et quatrieme de la norme ISO 7816. avec des lecteurs de cartes a 
puce specifiques, connectes aux ports USB d'un ordinateur hote et effectuant 
une conversion de protocole USB/ISO. De tels lecteurs communiquent, d'une 
part, avec I'ordinateur h6te selon le systeme USB et, d'autre part, avec la carte, 

20 selon le systeme ISO. 

Toutefois. ces lecteurs sont tres coOteux. En effet, ils doivent comporter 
des moyens pour g<§n6rer une horloge destinee a cadencer le fonctionnement 
de I'unite centrale de traitement CPU (Central Processing Unit) du micro- 
controleur de la carte via la plage de contact Clock (CLK) de la carte, lis doivent 

25 en outre comporter des moyens pour generer un signal de remise a zero et 
pour transmettre ce signal a ladite carte, via une plage de contact specifique de 
celle-ci, la plage dite de Reset (RST). 

De plus, la carte etant finalement une carte ISO pure, les procedes de 
communication avec cette carte ne montrent pas les avantages precites du 
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systeme USB relatifs en particulier aux lignes conductrices en nombre limite et 
aux debits importants de donnees. 

Compte tenu de ce qui precede, un probleme que se propose de 
r§soudre I'invention est de realiser un procede de communication permettant 
5 de connecter un objet portatif tel qu'une carte & puce a moindres couts a une 
station de travail telle qu'un ordinateur personnel selon le systeme USB. 

La solution proposee de ('invention a ce probleme pose a pour premier objet 
un procede de communication entre, d'une part, une station hote telle q'un 
ordinateur personnel et, d'autre part, un objet portatif a microcontroleur tel 
10 qu'une carte a puce, ledit objet portatif etant connecte, par un systeme de bus, 
a ladite station hote, caracterise en ce qu'il comporte une etape selon laquelle 
une requete specifique est communiquee a I'objet portatif a microcontroleur par 
la station hote. 

De maniere avantageuse, le systeme de bus est un systeme de bus serie 

15 universel USB et en ce que la requete specifique est communiquee a I'objet 
portatif & microcontroleur selon le mode transfert de controle dudit systeme ; la 
requete specifique est une requete specifique qui assure une fonctionnalite 
d'un lecteur d'objet portatif a microcontroleur ; !e microcontroleur comporte un 
ensemble associant une unite centrale de traitement ainsi qu'une memoire 

20 volatile et en ce que la requete specifique est une requete (DoResetO) qui 
declenche une remise a zero de la memoire volatile dudit ensemble ; la requete 
specifique est une requ§te (GetATRQ) qui permet de recuperer une chaine de 
reponse a une remise a zero de Tobjet portatif ; la requete specifique est une 
requete (SendAPDUO) qui permet a la station hote d'envoyer a Tobjet portatif 

25 une entete d'une commande ; la requete specifique est une requete specifique 
(GetDataO) qui permet d la station hote de recuperer des donnees envoyees 
par Tobjet portatif et de recuperer un mot d'6tat ; la requete specifique est une 
requete (SendDataQ) qui permet a la station hote de communiquer des 
donnees a Tobjet portatif ; la requete specifique est une requete (IsReadyO) qui 

30 permet d'eviter un declenchement, par la station hote, d'un mode de 
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consommation de courant electrique reduit chez I'objet portatif ; I'objet portatif 
communique une reponse (OS-STATUS) a la station note en reponse a la 
requete permettant le declenchement, par ladite station, d'un mode de 
consommation de courant electrique reduit chez I'objet portatif, cette reponse 
5 etant codee de maniere a definir un etat courant de I'objet portatif ; I'etat 
courant de I'objet portatif est un etat de mutisme ou un etat selon lequel la carte 
est en cours de traitement ; I'objet portatif a microcontroleur est une carte a 
microcontroleur ; le microcontroleur de la carte comporte une memoire non 
volatile qui comprend un systeme d'exploitation susceptible de communiquer 
10 selon un protocole mettant en oeuvre des commandes APDU telle que definies 
dans la norme IS07816. 

Par ailleurs, la solution proposee de I'invention a ce probleme pose a pour 
second objet un objet portatif a microcontroleur tel qu'une carte a puce, apte a 
communiquer avec une station note telle qu'un ordinateur personnel, par un 
15 systeme de bus connecte, d'une part, audit objet portatif et, d'autre part, a 
ladite station note, caracterise en ce que I'objet portatif est apte a communiquer 
avec la station hdte, directement. 

De maniere avantageuse, I'objet portatif est constitue par une carte a puce ; 
le systeme de bus est un systeme de bus USB ; I'objet portatif comporte un 
20 ensemble associant une unite centrale de traitement et une memoire non 
volatile embarquant un systeme d'exploitation apte a assurer une gestion de 
commandes APDU telle que definies dans la norme IS07816. 

L'invention sera mieux comprise a la lecture de I'expose non limitatif qui va 
suivre. Cet expose doit etre lu au regard des dessins annexes, dans lesquels : 
25 - la figure 1 represents des schemas de connexion possibles entre une 
station de travail note et un objet portatif selon I'invention ; 

- la figure 2 montre un mode de connexion d'un ordinateur personnel note a 
une carte a puce selon I'invention ; 
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- la figure 3 montre, en perspective, un 6l6ment d'un connecteur apte a 
recevoir une carte a puce pour une connexion a un ordinateur hote selon 
Tinvention ; 

- la figure 4 montre, en vue de face agrandie, les contacts d'une carte a 
5 puce destinee a une connexion a un ordinateur hote selon Tinvention ; 

- la figure 5 schematise differents elements intervenant dans le 
fonctionnement d'un microcontroleur d'une carte destinee a une connexion a 
un ordinateur hote selon Tinvention ; 

- la figure 6 schematise une architecture logique d'un systeme de 
10 communication entre une carte et une application logicielle d'un ordinateur hote 

selon Tinvention ; 

- la figure 7 montre le deroulement d'une cession de communication avec 
une carte a puce selon Tinvention ; 

- les figures 8A et 8B montrent des transactions qui ont lieu dans un mode 
15 d'execution d'une commande de type ISO 1 par la carte ; 

- les figures 9A a 9D montrent des transactions qui ont lieu dans un mode 
d'execution d'une commande de type ISO 2 par la carte ; et 

- les figures 10A a 10D montrent des transactions qui ont lieu dans un mode 
d'execution d'une commande de type ISO 3 par la carte. 

20 L'invention s'applique en particulier dans le cadre de la securisation d'une 
station hote, par exemple munie d'un systeme d 'exploitation distribue par la 
societe Microsoft sous la denomination Windows 2000 protegee en tant que 
marque. Ce systeme d 'exploitation, ainsi que certaines applications logicielles 
congues pour ce systeme d'exploitation, prevoient ['utilisation d'une carte 

25 destinee notamment a la securisation de transferts de donnees, par exemple a 
la signature de mels, et a la securisation d'acces aux reseaux informatiques, 
par exemple au moyen d'algorithmes d'authentification ou de non-repudiation. 
De maniere generate, Tinvention peut etre mise en oeuvre sur toutes les cartes 
dont les systemes d'exploitation sont compatibles avec les parties troisieme et 

30 quatrieme de la norme ISO 7816. 
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A la figure 1, on a schematise une station note 1 comportant un repartiteur 
(Hub) integre 2, ledit repartiteur 2 etant muni de ports 21 , 22 et 23 specifiques 
definis dans la version 1.1 de la norme USB publiee le 23 septembre 1998. Ces 
ports USB peuvent etre connectes a un objet portatif 3 a microcontr6leur selon 
5 I'invention, soit directement, comme c'est le cas des objets connectes aux ports 
21 et 22, soit de maniere indirecte, via un autre repartiteur 4, comme c'est le 
cas des objets connectes au port 23. 

Ainsi que cela est montre a la figure 2, la station hote est par exemple une 
station de travail formee par un ordinateur personnel 1 et I'objet portatif a 
10 microcontrdleur est une carte a puce 3. La carte a puce 3 est connectee a un 
connecteur 5 qui n'est pas un lecteur, un lecteur disposant en effet de moyens 
actifs pour lire et/ou ecrire une carte et/ou pour permettre cette lecture et/ou 
cette ecriture. 

L'ordinateur 1 possede classiquement une unite centrale 11 reliee a un 

15 moniteur 12 et a un clavier. L'unite centrale 11 comporte une carte mere. Cette 
carte mere comprend en particulier un microprocesseur, des barrettes de 
memoire volatile. Elle est reliee a un disque dur, qui constitue la memoire de 
masse de l'ordinateur, ainsi qu'a un port USB au moins qui est compris dans un 
repartiteur integre a l'ordinateur. 

20 Si I'on se rapporte maintenant a la figure 6, il apparaTt que l'ordinateur h6te 
1 comporte au moins une application logicielle 13 utilisant une carte a puce. II 
comporte en outre une partie logicielle PC/SC 14, qui est chargee d'assurer la 
gestion de I'interface utilisee par I'application 13. II comporte encore un logiciel 
pilote intermediate 15 compose de deux parties logicielles principals non 

25 representees sur la figure 6. II s'agit d'une premiere partie chargee en memoire 
vive de l'ordinateur h6te au demarrage, qui assure I'interface avec la partie 
logicielle PC/SC 14 et qui simule la presence d'un lecteur d'une ou plusieurs 
cartes a puce selon I'invention connectees a l'ordinateur h6te. C'est un lecteur 
virtuel. II s'agit en outre d'une seconde partie enregistree dans la memoire de 

30 masse de l'ordinateur h6te, qui est chargee dans sa memoire vive lorsqu'une 
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carte est connectee a Tordinateur hote, adressee et configuree. Cette seconde 
partie est chargee d'acheminer les informations issues de la partie PC/SC ou 
issues de ia carte vers leurs destinataires respectifs et effectue une conversion 
des donnees. II comporte par ailleurs une partie controleur de I'hote 16 qui est 
5 chargee de gerer la repartition des donn6es sur le bus USB. II comporte enfin 
une partie hardware 17 qui constitue I'interface entre I'hote et le mode 
exterieur. 

La carte 3 montree a la figure 2 est par exemple une carte au format ISO 
standard ou une carte au format dit plug-in decrit dans cette meme norme 

10 IS07816 ou dans la norme ETSI GSM 11.11. Une telle carte est representee 
plus en details & la figure 3. Elle comporte un corps 31 de carte plastique dans 
lequel on a insere un module electronique comprenant un microcontroleur 
connecte, par des fils de connexion, a des plages 32 de contact affleurantes a 
la surface dudit corps de carte. 

15 La figure 4 represente les plages de contacts 32 de la carte 3. Elles sont par 
exemple au nombre de huit. II s'agit des plages C1, C2, C3, C4, C5 f C6, C7 et 
C8. Les plages C1 et C5 sont respectivement connectees a des plots Vcc et 
GND du microcontrdleur de la carte et qui servent a Palimentation du 
microcontroleur. Les plages C4 et C8 sont des plages respectivement 

20 connectees a des plots D+ et D- dudit microcontroleur, qui constituent une 
paire differentielle pour une transmission de donnees selon le systeme de bus 
USB. Les autres plages sont utilisees pour une transmission des donnees 
selon la norme ISO, sans utilisation du systeme precite de bus USB. 

Le microcontroleur 33 de la carte 3 est schematise £ la figure 5. II comporte 

25 un ensemble 331 associant une unite centrale de traitement CPU ainsi que des 
memoires volatile RAM, non volatile ROM et EEPROM, la m6moire ROM 
embarquant le systeme d'exploitation de la carte. II comporte en outre une 
interface de communication 332 selon le systeme ISO, un moteur USB 333 
associe, d'une part, a un systeme de transmission 334 et, d'autre part, a des 

30 registres 335, ainsi qu'une External Block Interface (EBI) 336, c'est-a-dire une 
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interface de bloc externe. Le systeme de transmission est relie au moins aux 
plots D+ et D- de la carte. II est en outre relie aux plots Vcc et GND pour 
I'alimentation. Le systeme d'exploitation 337 de la carte, I'EBI 336 et le moteur 
USB 333 sont representes a la figure 6. 
5 Ainsi que cela est montre a la figure 3, la carte est en pratique inseree dans 
un connecteur 5 de carte. Dans I'invention, ce connecteur 5 est reduit. II 
possede uniquement un connecteur USB 51 et un connecteur 52 pour la carte 
3 - 

Selon la norme USB, les donnees peuvent etre transferees selon deux 
10 vitesses une Vitesse pleine (Full speed) autorisant un debit de donnees a 12 
Mb/s et une Vitesse basse (Low speed) autorisant un debit de donnees a 1 , 5 
Mb/s. Dans I'invention, les donnees sont transferees a la Vitesse basse. Ainsi, il 
est possible de generer un signal d'horloge interne a partir des lignes de 
donnees du bus USB. De ce fait, le connecteur 5 ne comporte pas de moyens 
15 pour fournir un signal d'horloge a la carte 3. 

Selon la norme USB, quatre modes de transfert de donnees sont prevus. 
Les modes de transfert en vrac (Bulk transfert) et isochrone (Isochronous 
transfert) sont uniquement prevus pour etre mis en oeuvre dans une 
communication a Vitesse pleine. Les modes de transfert de controle (Control 
20 transfert) et transfert avec interruption (Interrupt transfert) sont par contre 
prevus pour etre mis en oeuvre dans une communication a basse Vitesse ou a 
pleine Vitesse. 

Dans I'invention, la carte forme un peripherique USB qui communique 
directement avec I'ordinateur hote dans le mode transfert de controle. La carte 

25 est done capable d'interpreter et de traiter des donnees qui lui sont adressees 
sous forme de signaux USB a basse vitesse, sur le bus USB. Elle dispose par 
ailleurs d'un programme permettant le traitement des requetes USB propres au 
transfert de controle et en particulier des requites classiques, qui permettent a 
I'ordinateur h6te de recuperer les descripteurs de la carte, de lui attribuer une 

30 adresse et de la configurer. En effet, selon la norme USB, ('utilisation du mode \ 

5 

•1 

| 
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transfert de controle est requise pour tous les peripheriques USB pour la 
recuperation de leurs descripteurs, ('attribution de leur adresse et leur 
configuration. La norme USB ne suggere pas d'utiliser le mode transfert de 
transfert pour une gestion des transferts de donnees en dehors d'etapes de 
5 controle du type precite. 

En plus des requetes USB classiques permettant la reconnaissance, 
Tadressage et la configuration du p6ripherique, six requetes vendeur- 
specifiques (Vendor Specific) ont ete definies. La carte comporte des moyens 
pour reconnaitre et traiter ces requetes vendeur-specifiques. Ces requetes 

10 vendeur-specifiques permettent de reproduire le fonctionnement d'une carte 
compatible ISO 7816-3 et ISO 7816-4 associee a un lecteur actif de carte a 
puce, en utilisant le protocole USB et le bus de donnees associe et sans utiliser 
d'interface supplemental que constituerait ce lecteur. Elles sont chargees en 
particulier d'assurer le traitement des commandes APDU et les phases 

15 d'initialisation ou de reinitialisation du microcontroleur de la carte sans 
reinitialisation de Pinterface de communication avec Tordinateur hote. 

La carte est geree, d'une part, par le pilote instaile sur I'ordinateur hote qui 
est responsable de renvoi des requetes vendeur-specifiques et, d'autre part, 
par le moteur USB contenu dans le microcontroleur de la carte et son systeme 

20 d'exploitation, tous deux etant responsables de la reconnaissance et du 
traitement de ces memes requetes. 

En definitive, la carte fonctionne «comme si» elle etait reliee a un lecteur de 
carte a puce, en utilisant le protocole USB, ce qui signifie que le changement 
^interface, lecteur de carte a puce ISO vers connecteur USB, est transparent 

25 pour le niveau applicatif de Tordinateur hote. 

Les requetes vendeur-sp§cifiques selon Tinvention sont definies dans le 
tableau ci-apr6s. Dans ce tableau : 

- Les valeurs donnees dans la colonne bmRequest identifie les 
caracteristiques des requetes. Si la valeur du bmRequest est 40h, la requete 

30 est une requete vendeur-sp6cifique dont la phase de donnee est transmise de 
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I'hote vers la carte. Si la valeur du bmRequest est COh, la requete est une 
requete vendeur-specifique dont la phase de donnee est transmise de la carte 
vers I'hote. 

- Les valeurs donnees dans la colonne bRequest permettent au moteur 
USB d'identifier les requetes DoReset() et IsReadyO en ne testant qu'un seul 
bit a chaque fois, les bits 4 et 5 si le bit de poids faible est le bit 0. 

- Les valeurs donnees dans la colonne wValue sont specifiques a la 
requete. 

- II en va de meme des valeurs donnees dans la colonne wlndex. 

- Les valeurs donnees dans la colonne wLength specifient le nombre 
d'octets dans la phase de donnees de la requete. 

- Le mode indique dans la derniere colonne du tableau correspond au 
sens de circulation des donnees USB. «OUT» signifie que les donnees 
circulent de I'ordinateur hote vers la carte et « IN » signifie que les informations 

15 circulent de la carte vers I'ordinateur hote, pendant la phase de donnees. 
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Requete 


bmRequest 


bRequest 


wValue 


wlndex 


wLength 


Mode 


DoReset() 


40h 


90h 


OOOOh 


OOOOh 


OOOOh 


OUT 


GetATRQ 


COh 


83h 


0000b 


OOOOh 


Lgth 


IN 


GetData() 


COh 


81h 


OOOOh 


OOOOh 


Lgth 


IN 


IsReadyO 


COh 


AOh 


OOOOh 


OOOOh 


0100h 


IN 


SendAPDU() 


40h 


80h 


OOOOh 


OOOOh 


0500h 


OUT 


SendData() 


40h 


82h 


OOOOh 


OOOOh 


Lgth 


OUT 



20 



de la carte. II s'agit des requetes DoReset() et GetATR(). 

La requete DoReset() permet de declencher une remise a zero du 
microcontroleur et de la memoire vive RAM de I'ensemble 331 associee sans 
remettre a zero Nnterface de communication avec I'ordinateur hote. Elle est 
traitee entierement par le moteur USB 333 contenu dans le microcontroleur et 
ne necessite aucune intervention de la part du systeme d'exploitation de la 
carte. Le traitement automatique de la requete vendeur-specifique DoResetQ 
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permet a la carte a puce de gerer elle-meme le signal Reset et de conserver 
ainsi, associee £ la requete vendeur-specifique GetATR(), le fonctionnement 
normal du signal Reset dans le mode ISO. 

La requete GetATR() permet de recuperer la chame de reponse a la 
5 remise a zero (ATR pour Answer To Reset) de la carte. Cette reponse est 
definie dans la norme ISO 7816-3. Elle identifie la carte. 

On notera que la plupart des peripheriques disposent d'une remise a zero 
(Reset), qui est utilisee en cas de fonctionnement anormal. Le protocoie USB 
prevoit ce cas avec la possibility offerte a I'ordinateur hote d'envoyer un signal 

10 USB de remise a zero a chaud (USB Warm Reset) qui provoque une 
reinitialisation complete du p6ripherique. Cependant, les applications 
s'appuyant sur I'utilisation de cartes a puce peuvent se servir de la remise a 
zero de la carte a puce dans le but de reinitialiser simplement la memoire vive 
geree par le microcontroleur de ladite carte. Dans ce cas, la remise a zero de 

15 Nnterface de communication avec I'ordinateur hote n'est pas necessaire et 
genere une perte de temps. L'utilisation du signal «USB Warm Reset» n'est 
done pas justifiee. D'autre part, ce signal «Reset» doit etre complement 
asynchrone, ce qui signifie qu'il doit pouvoir etre pris en compte quel que soit 
T6tat de la carte ou de la commande en cours de traitement, si une commande 

20 est effectivement en cours de traitement, ce qui justifie encore une fois Temploi 
d'un lecteur de carte a puce dans les solutions proposees actuellement selon 
Tetat de la technique qui effectue lui meme la remise a z6ro du microcontroleur 
et de sa memoire associee par la plage de contact connectee au plot de 
contact Reset du microcontrdleur. 

25 Ensuite, quatre requetes sont d6diees au traitement des commandes 
APDU. II s'agit des requetes SendAPDU(), GetData() et SendData(). 

La requete SendAPDUO permet d'envoyer & la carte Tentete d'une 
commande ISO APDU, e'est-a-dire les portions CLAsse, INStruction, parametre 
P1, parametre P2, et parametre P3. 
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La requete GetDataO permet a la fois de recuperer les donnees renvoyees 
par la carte dans le cadre d'une commande ISO de type 2 et de recuperer ie 
mot d'etat defini par la norme IS07816, qui indique au monde exterieur Tissue 
de la commande precedemment envoyee lorsque I'execution de la commande 
5 est terminee. 

La requete SendData() permet d'envoyer des donnees en plus des 
parametres de I'entete de la commande dans le cadre d'une commande ISO de 
type 3. 

Enfin. la quatrieme requete est une requete qui est utilisee pour eviter le 
10 declenchement du mode de consommation reduite et pour gerer le 
deroulement des commandes APDU. II s'agit de la requete lsReady(). Le 
traitement semi-automatique de la requete vendeur-specifique IsReadyO 
permet d'eviter le passage en faible consommation de courant durant 
I'execution d'une commande ISO APDU. En effet, le temps de traitement d'une 
15 commande ISO APDU par la carte n'est pas previsible. Or, le protocole USB 
prevoit un mode de faible consommation de courant lorsque le bus n'est pas 
utilise pendant un certain temps, ce qui se produit si le temps de traitement de 
la commande ISO APDU est trap long. Cette requete evite ainsi le basculement 
dans ce mode pendant le traitement d'une commande ISO APDU tout en 
20 I'autorisant dans les autres cas. Plus precisement, elle permet de recuperer 
I'etat du systeme d 'exploitation de la carte ou de la commande en cours de 
traitement, si une commande est effectivement en cours de traitement. Elle est 
envoyee periodiquement, par exemple toutes les 5 ms, par le pilote 15 contenu 
dans I'ordinateur note pendant le traitement par la carte d'une commande ISO 
25 APDU. Elle peut etre traitee par le moteur USB 333 contenu dans le 
microcontroleur. C'est le cas, en particulier, lorsque le microcontroleur est 
occupe (BUSY) ou en mutisme (MUTE) et ne peut done pas repondre. Elle peut 
aussi etre traitee par le systeme d'exploitation de la carte, en particulier lorsque 
celui-ci est libre et peut done repondre. 
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L'ensemble de ces requetes vendeur-specifiques permet de reconstituer, en 
plus du fonctionnement classique de la carte a puce dans le mode ISO et du 
fonctionnement d'un peripherique standard USB, le comportement d'un lecteur 
de carte a puce associe. 
5 Par ailleurs, une reponse dite OS_STATUS a la requete lsReady() a 
egalement ete definie. Cette reponse est codee sur un octet dont les quatre 
premiers bits definissent I'etat courant de la carte et les quatre derniers bits 
precisent cet etat. 

Ainsi, lorsque le bit 7 est a 1 , cela signifie que la carte est dans un etat de 

10 mutisme dit MUTE. Lorsque le bit 6 est a 1, cela signifie que le systeme 
d'exploitation de la carte est en cours de traitement et que par suite ce systeme 
n'est pas disponible pour un autre traitement. On dit alors que la carte est dans 
un etat BUSY. Lorsque le bit 5 est a 1, cela signifie que le traitement de la 
commande anterieure recue par la carte est termine et que le systeme 

15 d'exploitation est pret a envoyer un mot d'etat SW1 SW2. On dit alors que la 
carte est dans I'etat SWP pour Status Word Phase (phase de mot d'etat). 
Lorsque le bit 4 est a 1 , cela signifie que le systeme d'exploitation de la carte 
est pret a envoyer ou a recevoir des donn^es relatives a une commande 
anterieure. On dit que la carte est dans I'etat DTP pour Data Transfer Phase 

20 (phase de transfert de donnees). 

Par ailleurs, les bits 3, 2, 1 et 0 precisent I'etat courant. lis sont utiles par 
exemple dans le cas d'une commande tres longue, pour 6viter ce qu'on appelle 
un «Time Out», c*est-a-dire un depassement du temps maximum prevu pour 
une commande. Dans ce cas, la valeur est incrementee de maniere cyclique. 

25 Elle reprend done a Oh apres la valeur Fh, ce qui permet au pilote contenu 
dans le PC de detecter une activite. 

L'encapsulation pure, par le protocole USB, du protocole de communication 
defini dans les parties 3 et 4 de la norme ISO 7816, imposerait une perte de 
temps liee au fait que la carte ne peut transmettre des informations sur le bus 

30 USB que lorsqu'elle est sollicitee par I'ordinateur hdte et que certaines de ces 
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informations ne sont pas utiles dans le cadre de I'execution d'une commande 
APDU. L'utilisation de la requite vendeur-specifique lsReady() permet de 
reduire ce temps en indiquant au pilote de la carte non seulement I'etat courant 
de la carte, mais aussi I'etat courant de la commande, ce qui permet de 
5 supprimer I'etape d'octet de procedure (procedure byte) definie dans la norme 
ISO 7816-3. 

La norme ISO 7816-3 prevoit la gestion d'un «Time-Out» si le systeme 
d'exploitation de la carte ne renvoie pas de donnees au bout d'un temps defini 
par la chaTne d'ATR. Pour les commandes ne pouvant etre traitee dans ce 
10 temps, la norme prevoit egalement l'utilisation de I'octet 60h, qui constitue une 
valeur reservee, permettant d'indiquer que la carte est toujours en cours de 
traitement. L'envoi de cet octet par la carte a pour effet de reinitialiser le 
compteur charge de determiner le «Time-Out». La gestion de ce «Time-Out» 
peut etre reproduce grace & la valeur renvoyee a la requete lsReady(). 
15 A la figure 7, on a montre le deroulement d'une cession de communication 
avec une carte a puce selon I'invention. Cette figure montre, dans sa partie 
gauche, les traitements effectues par le moteur USB de la carte et, dans sa 
partie droite, les traitements effectues par le systeme d'exploitation de la carte. 
En ce qui concerne les traitements effectues par le systeme 
20 d'exploitation de la carte, il s'agit en particulier des traitements suivants. 

«Connexion de la carte» sur un port USB de I'ordinateur h6te. 
L'ordinateur note est alors informe de la connexion de la carte, qui constitue un 
nouveau peripherique USB. L'ordinateur alimente ensuite la carte, ce qui a pour 
effet de declencher une remise a zero de celle-ci. Cette remise a zero 
25 comprend une remise a zero de la memoire RAM de la carte, de I'EBI 336, des 
registres 335 et du systeme de transission 334. 

«Enumeration et initialisation de I'ensemble des composants de la 
carte». L'enumeration est une operation USB qui permet de rendre la carte 
operationnelle, c'est-a-dire adressee et configuree. Une fois que la carte a fait 
30 I'objet d'une remise a zero selon le traitement precedent, elle peut s'identifier 
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aupres de Pordinateur hote. C'est la phase dite d'enumeration durant laquelle la 
carte envoie un certain nombre d'informations a Tordinateur hote sous forme de 
descripteurs. L'ordinateur hote attribue alors une adresse a la carte et la 
configure. La carte apparait alors prete a etre utilisee. 
5 «GetATR() re?u». Suite a l'6tape pr6cedente d'enumeration et 

d'initialisation, la carte attend une requete vendeur-specifique GetATR(). C'est 
d'ailleurs la seule requete vendeur-specifique autorisee a ce stade. 

«La carte renvoie la chaine ATR». Lorsque la requete vendeur- 
specifique GetATRQ a ete re?ue, la carte renvoie la chaTne ATR. Ainsi, au 

10 niveau applicatif de l'ordinateur hote, le "Reset" existant sur les cartes 
uniquement compatibles avec la norme ISO 7816 est simule. 

«OS_STATUS = 00h» : Le systeme d 'exploitation de fa carte se place 
dans une configuration dans laquelle il est pret a traiter une commande ISO 
APDU en positionnant son octet d'etat a OOh. 

15 «SendAPDU() re9u» : Le systeme d'exploitation de la carte regoit I'entete 

d'une commande APDU sous la forme d'une requite USB vendeur-specifique. 

«OS_STATUS = BUSY» : Le systeme d'exploitation de la carte se 
prepare a traiter Tentfete de la commande APDU et devient done indisponible. 
Pour indiquer cette indisponibilite au monde exterieur, en pratique a Tordinateur 

20 hote, ledit systeme d'exploitation met a jour son octet d'etat en le positionnant a 
"BUSY". A ce stade, les requetes provenant de Tordinateur hote sont traitees 
par le moteur USB de la carte. 

«Traitement commande» : Le systeme d'exploitation de la carte traite 
Tentete de la commande APDU. 

25 A ce stade, plusieurs cas peuvent se presenter. 

Dans un premier cas, la commande est une commande APDU ISO de 
type 1, e'est-a-dire une commande APDU qui est representee uniquement par 
son entete et dont I'execution donne lieu & remission d'un mot d'etat par la 
carte, ou une commande ISO de type 2 ou 3 en erreur, une commande ISO de 

30 type 2 etant une commande definie par son entete dont l'ex6cution donne lieu a 
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remission de donn6es et d'un mot d'etat par la carte et une commande ISO de 
type 3 etant une commande definie par son entete et des donnees et dont 
I'execution donne lieu & remission d'un mot d'etat par la carte. Dans ce cas, les 
etapes suivantes sont mises en oeuvre. 
5 «OS_STATUS = SWP» : Le systeme d'exploitation de la carte est pret a 

renvoyer le mot d'etat, qui est de nouveau disponible pour traiter les requetes 
qui lui sont envoyees, et attend une requete lsReady() pour Pindiquer a 
I'ordinateur hote. Get octet d'6tat est ainsi mis a jour. II prend la valeur "SWP". 
«lsReady() re?u» : Le systeme d'exploitation de la carte re?oit ensuite la 

10 requete vendeur-specifique lsReady(). Le role de cette requete est d'indiquer 
au monde exterieur I'etat du systeme d'exploitation de la carte qui est "MUTE" 
ou "BUSY", ou alors, I'etat de la commande ISO APDU en cours de traitement 
qui est "SWP" ou "DTP". Dans le cas present, la reponse a cette requete est 
"SWP". Elle indique a I'ordinateur hote qu'il doit envoyer une commande 

1 5 GetData() pour recuperer le mot d'etat. 

«Renvoie OS_STATUS» : le systeme d'exploitation de la carte renvoie 
son octet d'etat a I'ordinateur hote et attend une requite vendeur-specifique 
GetData(). 

«GetData() re?u» : Apres que la requete vendeur-specifique lui ait ete 
20 envoyee, le systeme d'exploitation de la carte regoit la requete GetData(), qui 
est destinee a permettre a I'ordinateur de recuperer des donnees renvoyees 
par le systeme d'exploitation de la carte, telles que, dans le cas present, le mot 
d'etat. 

«Renvoie le Mot d'Etato : En reponse a cette requete GetData(), le 
25 systeme d'exploitation de la carte renvoie le mot d'etat. II se replace ensuite 
dans une configuration dans laquelle il est pr§t a traiter une nouvelle 
commande ISO APDU et Ton revient alors a I'etape precitee «OS_STATUS = 
00h». 
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Les commandes APDU ISO de types 2 et 3 ont la particularity de 
posseder une phase de donnees, de la carte vers Thote pour les commandes 
IS02, et de I'hote vers la carte pour les commandes IS03. Dans ces deux cas, 
le systeme d'exploitation doit indiquer a I'ordinateur hote qu'il est pret pour la 
5 phase de donnees. Les etapes suivantes sont alors mises en oeuvre. 

«OS_STATUS = DTP» : Le systeme d'exploitation de la carte est pret 
pour la phase de donnees de la commande ISO APDU. II est done de nouveau 
disponible pour traiter les requetes qui lui sont envoyees et attend de recevoir 
une requete IsReadyQ pour indiquer cet etat de disponibilite au monde 
10 exterieur. L'octet d'etat est done mis a jour. II prend la valeur "DTP". 

«lsReady() regu» : Le systeme d'exploitation de la carte re?oit une 
requite vendeur-sp6cifique IsReadyQ. Le role de cette requete est d'indiquer a 
I'ordinateur hote I'etat du systeme d'exploitation de la carte qui est "MUTE" ou 
"BUSY", ou alors, Tetat de la commande ISO APDU en cours de traitement qui 
15 est "SWP" ou "DTP". Dans le cas present, la reponse a cette requete est 
"DTP". Dans un premier cas, cette reponse indique a Tordinateur hote qu'il doit 
envoyer une requete GetData(P3) pour recuperer les donnees qui constituent 
la reponse a la commande ISO APDU. Ces donnees comportent alors P3 
octets, P3 etant Tun des parametres de la commande ISO APDU. Dans un 
20 second cas, cette reponse indique a Tordinateur hote qu'il doit envoyer une 
requete SendData(P3) pour envoyer les donnees complementaires de la 
commande ISO APDU. Ces donnees comportent alors P3 octets, P3 etant Tun 
des parametres de la commande ISO APDU. 

«Renvoie OS_STATUS» : Le systeme d'exploitation de la carte renvoie 
25 son octet d'etat £ Tordinateur hote et attend, soit une requete GetData(P3), soit 
une requete SendData(P3). 

Deux cas peuvent alors se presenter. 

Le premier cas est celui d'une commande APDU IS02, dans le cas 
nominal ou aucune erreur relative a Tentete de la commande ou dans le 
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contexte courant de la carte n'a ete detectee. Le systeme d "exploitation de la 
carte attend alors une requete GetData(P3). 

«GetData() recu» : Le systeme d'exploitation de la carte recoit la requete 
GetData(). Le role de cette requete est de recuperer des donnees renvoyees 
par le systeme d'exploitation, telles que, dans le cas present, les donnees qui 
constituent la reponse a la commande ISO APDU de type 2. 

«La carte renvoie les donnees» : Une fois la requeue GetDataO recue, la 
carte renvoie les donnees qui constituent la reponse a la commande ISO 
APDU et se place dans une configuration ou elle est prete a renvoyer le mot 
d'etat et I'on revient alors a I'etape precitee «OS_STATUS = SWP». 

Le second cas est celui d'une commande ISO APDU de type 3, dans le 
cas nominal ou aucune erreur n'a ete detectee dans I'entete de la commande 
ou dans le contexte courant de la carte. Le systeme d'exploitation attend alors 
une requete SendData(P3). 

«SendData() recu» : Le systeme d'exploitation de la carte recoit la 
requete SendData(). Cette requete permet I'envoi de donnees 
complementaires, qui sont necessalres a I'execution de la commande ISO 
APDU de type 3. 

«La carte recupere les donnees» : Une fois la requete recue, la carte 
recupere les donnees complementaires de la commande ISO APDU de type 3 
et se place dans une configuration qui lui permet de traiter le reste des 
donnees de la commande. 

«OS_STATUS = BUSY» : Comme le systeme d'exploitation de la carte 
est en cours de traitement, il n'est plus capable de traiter les requetes qui lui 
sont envoyees. II indique cet etat en positionnant I'octet d'etat a "BUSY". Au 
cours de cette phase, c'est le moteur USB de la carte qui traite les requetes 
envoyees par I'ordinateur note. 

«Traitement de la commande» : Le systeme d'exploitation termine le 
traitement de la commande ISO APDU et se place dans une configuration ou il 
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est pret a renvoyer le mot d'etat. On revient alors a I'etape precitee 

«OS_STATUS = SWP». 

Un dernier cas traite par le systeme d'exploitation de la carte est celui 

d'une erreur grave survenant au cours de I'execution d'une commande ISO 
5 APDU quelconque, par exemple suite a une attaque securitaire ou a une 

corruption de donnees. Dans ce cas, le systeme d'exploitation de la carte est 

place en mutisme et on a I'etape suivante. 

«OS_STATUS = MUTE» : Le systeme d'exploitation de la carte met a 

jour son octet d'etat "MUTE" pour indiquer a I'ordinateur hote qu'il est 
10 indisponible jusqu'a la prochaine requete DoReset() ou jusqu'a ce que la carte 

soit deconnectee. Durant cette phase, c'est le moteur USB qui traite les 

requetes envoy6es par I'ordinateur hote. 

En ce qui concerne les traitements effectues par le moteur USB, il s'agit 

en particulier des traitements suivants. 
1 5 Lorsque I'OS est indisponible, c'est-a-dire dans les cas OS_STATUS = 

BUSY ou OS_STATUS = MUTE, les requetes envoyees par Tordinateur hote 

sont traitees par le moteur USB. Par aiileurs, la requete DoReset() est toujours 

traitee par le moteur USB de maniere a eviter toute intervention du systeme 

d'exploitation de la carte dans sa remise a zero. 
20 On distingue done trois cas. Le premier, qui n'apparaTt pas a la figure 7, 

correspond 3 Tensemble des requetes qui ne sont pas indiquees comme 

traitees par le moteur USB. Pour ces requetes, le moteur USB se contente 

d'indiquer a Pordinateur hote qu'elles sont hors contexte. 

Le second cas est celui de la requete DoResetQ et les etapes suivantes 
25 sont suivies. 

<(DoReset() regu» : Quel que soit Tetat du systeme d 'exploitation de la 
carte ou de la commande ISO APDU en cours de traitement, cette requete est 
toujours traitee par le moteur USB. Elle declenche une remise a zero de Tunite 
centrale de traitement de la carte associee a sa memoire et seulement de cette 
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unite centrale associee a sa memoire, puisque 1'interface de communication 
USB formee par la configuration et Padresse du peripherique restent intactes. 

«Sequence de remise a zero» : L'unite centrale de traitement de la carte 
et sa memoire sont reinitialises. Le systeme d'exploitation de la carte attend 
5 une requete GetATR(). La sequence de remise a zero replace le systeme 
d'exploitation de la carte dans un etat qui lui permet de traiter des requetes qui 
lui sont envoyees. 

Le troisieme cas est celui de la requete IsReadyO, lorsque le systeme 
d'exploitation de la carte est indisponible. Les etapes suivantes sont alors 
0 su ivies. 

«lsReady() re9u» : Le systeme d'exploitation de la carte recoit la requete 
lsReady(). Le role de cette requete est d'indiquer a I'ordinateur hote I'etat 
"MUTE" ou "BUSV'du systeme d'exploitation de la carte, ou I'etat "SWP" ou 
"DTP" de la commande ISO APDU en cours de traitement. Le systeme 
5 d'exploitation de la carte est indisponible "MUTE" ou "BUSY". Les autres cas 
sont traites par le systeme d'exploitation de la carte. 

«Le moteur USB renvoie OS_STATUS» : Le moteur USB indique a 
I'ordinateur hote I'etat du systeme d'exploitation de la carte en renvoyant son 
octet d'etat. 

De cette maniere, on reproduit le fonctionnement d'une carte ISO associe a 
son lecteur de carte a puce. 

L'objet de la figure 7 ayant marntenant ete explique, la suite de I'expose 
constitue une explication de l'objet des figures 8A et 8B, 9A a 9D et 10A a 10D. 

Pour une commande APDU de type 1 telle que montree a la figure 8A, 
I'entete de la commande est suffisant pour executer entierement la commande 
et la seule reponse du systeme d'exploitation de la carte est le mot d'etat. Ainsi, 
selon le protocole ISO, la communication est divisee en au moins deux etapes. 
Dans une premiere etape, I'ordinateur envoie Tentete de la commande. Puis, 
dans une seconde etape, la carte envoie un octet 60h de remise a zero du 
compteur charge de definir le time-out ou un mot d'etat SW1 SW2 (figure 8B). 
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Dans le cas ou I'octet 60h est envoye, des etapes subsequentes consistent en 
renvoi d'autres octets 60h ou non, une derniere etant toujours renvoi d'un mot 
d'etat SW1 SW2. Par contre, selon I'invention, I'etape montree a la figure 8B 
est supprimee. Elle est remplacee par la reponse de la carte a une commande 
5 IsReadyO envoyee par ordinateur hote. 

Pour une commande APDU ISO de type 2, I'entete de la commande debute 
son execution, mais la reponse du systeme d 'exploitation de la carte est 
composee de donnees en plus du mot d'etat. La communication est 
generalement divis^e en quatre etapes. Dans une premiere etape conforme a 

10 la figure 9A, rordinateur envoie I'entete de la commande. La seconde etape est 
classiquement utilisee dans une procedure ISO. Dans cette etape, I'ordinateur 
report I'octet de procedure 60h, INS ou SW1. Dans le cas ou I'octet de 
procedure est 60h, on retourne au cas decrit ci-dessus jusqu'a reception de 
I'octet INS ou SW1. Une fois que I'octet de procedure INS ou SW1 a ete re9u 

15 conformement & la figure 9B, on procede comme decrit ci-dessous en 
reference aux figure 9C et 9D. Toutefois, on notera que, dans I'invention, 
1'etape de la figure 9B est supprimee. En effet, elle est remplacee par la 
r6ponse de la carte a une commande IsReadyO envoyee par I'ordinateur hote. 
Si I'on se rapporte maintenant a la figure 9C, qui correspond au cas ou I'octet 

20 de procedure regu est INS, la carte renvoie les donn6es. Finalement, 
I'ordinateur attend I'octet de procedure, jusqu'a ce qu'il soit SW1, 
conformement £ la figure 9D. Si INS n'a pas ete regu mais SW1 a ete re9u 
directement, on regoit SW2 et la commande est terminee. Dans I'invention, les 
etapes montrees dans les figures 9C et 9D sont conservees sauf en ce qui 

25 concerne le cas vise dans la figure 9D dans lequel la carte renvoie I'octet de 
procedure 60h. 

Pour une commande APDU de type 3, la procedure est identique a la 
procedure decrite ci-dessus en reference a au traitement d'une commande ISO 
de type 2 sauf en ce qui concerne le sens d'emission des donnees qui n'est 
30 plus de la carte vers I'ordinateur mais de I'ordinateur vers la carte. 
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REVINDICATIONS 



1. Procede de communication entre, d'une part, une station hote telle q'un 
ordinateur personnel et. d'autre part, un objet portatif a microcontroleur tel 
qu'une carte a puce, ledit objet portatif etant connecte, par un systeme de 
bus, a ladite station hote, caracterise en ce qu'il comporte une etape selon 
laquelle une requete specifique est communiquee a I'objet portatif a 
microcontroleur par la station hote. 

2. Procede selon la revendication 1 , caracterise en ce que le systeme de bus 
est un systeme de bus serie universel USB et en ce que la requete 
specifique est communiquee a I'objet portatif a microcontroleur selon le 
mode transfert de controle dudit systeme. 

3. Procede selon I'une des revendications 1 ou 2, caracterise en ce que la 
requete specifique est une requete specifique qui assure une fonctionnalite 
d'un lecteur d'objet portatif a microcontr6leur. 

4. Procede selon I'une des revendications precedentes, caracterise en ce que 
le microcontrdleur comporte un ensemble associant une unite centrale de 
traitement ainsi qu'une memoire volatile et en ce que la requete specifique 
est une requete (DoReset()) qui declenche une remise a zero de la memoire 
volatile dudit ensemble. 

5. Procede selon I'une des revendications precedentes, caracterise en ce que 
la requete specifique est une requete (GetATR()) qui permet de recuperer 
une chaTne-de reponse a une remise a zero de I'objet portatif. 

6. Procede selon I'une des revendications precedentes, caracterise en ce que 
la requete specifique est une requete (SendAPDUO) qui permet a la station 
h6te d'envoyer a I'objet portatif une entete d'une commande. 

7. Procede selon I'une des revendications precedentes, caracterisee en ce 
que la requete specifique est une requete specifique (GetData()) qui permet 
a la station hote de recuperer des donnees envoyees par I'objet portatif et 
de recuperer un mot d'etat. 
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8. Procede selon Tune des revendications precedentes, caracterise en ce que 
la requete specifique est une requete (SendDataO) qui permet a la station 
note de communiquer des donnees a I'objet portatif. 

9. Procede selon I'une des revendications precedentes, caracterise en ce que 
la requete specifique est une requete (IsReadyO) qui permet d'eviter un 
declenchement, par la station note, d'un mode de consommation de courant 
electrique reduit chez I'objet portatif. 

10. Procede selon la revendication 9, caracterise en ce que i'objet portatif 
communique une reponse (OS-STATUS) a ia station hote en reponse a la 
requete permettant le declenchement, par ladite station, d'un mode de 
consommation de courant electrique reduit chez I'objet portatif, cette 
reponse etant codee de maniere a definir un etat courant de I'objet portatif. 

11. Procede selon la revendication 10, caracterise en ce que I'etat courant de 
I'objet portatif est un etat de mutisme ou un etat selon lequel la carte est en 
cours de traitement. 

12. Procede selon I'une des revendications precedentes, caracterise en ce que 
I'objet portatif a microcontroleur est une carte a microcontr6leur. 

13. Procede selon la revendication 12, caracterise en ce que le microcontroleur 
de la carte comporte une memoire non volatile qui comprend un systeme 
d'exploitation susceptible de communiquer selon un protocole mettant en 
oeuvre des commandes APDU telle que definies dans la norme IS07816. 

14.0bjet portatif a microcontroleur tel qu'une carte a puce, apte a communiquer 
avec une station hote telle qu'un ordinateur personnel, par un systeme de 
bus connecte. d'une part, audit objet portatif et, d'autre part, a ladite station 
hote, caracterise en ce que I'objet portatif est apte a communiquer avec la 
station hdte, directement. 

15. Objet portatif a microcontroleur selon la revendication 14, caracterise en ce 
qu'il est constitue par une carte a puce. 
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16.0bjet portatif selon Tune des revendications 14 ou 15, caracterise en ce que 
le systeme de bus est un systeme de bus USB. 

17,Objet portatif selon I'une des revendications precedentes, caracterise en ce 
qu'il comporte un ensemble associant une unite centrale de traitement et 
une memoire non volatile embarquant un systeme d 'exploitation apte a 
assurer une gestion de commandes APDU telle que definies dans la norme 
IS07816. 
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